home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13122 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.5 KB
  1. Path: howland.reston.ans.net!psinntp!psinntp!psinntp!psinntp!usenet
  2. From: grantp@usa.pipeline.com(Pete Grant)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: object creation from an abstract base class
  5. Date: 23 Mar 1996 18:22:26 GMT
  6. Organization: Kalevi, Inc.
  7. Message-ID: <4j1fh2$hvs@news1.h1.usa.pipeline.com>
  8. References: <31517CF6.7C6F@novell.com>
  9. NNTP-Posting-Host: 38.8.60.6
  10. X-PipeUser: grantp
  11. X-PipeHub: usa.pipeline.com
  12. X-PipeGCOS: (Pete Grant)
  13. X-Newsreader: Pipeline v3.5.0
  14.  
  15. On Mar 21, 1996 08:59:50 in article <Re: object creation from an abstract
  16. base class>, 'Sukanta Ganguly <sukanta_ganguly@novell.com>' wrote: 
  17.  
  18.  
  19. >Michael Catello wrote: 
  20. >>  
  21. >> Hello OOPsters, 
  22. >>  
  23. >> I was just looking for validation/other suggestions for a method I 
  24. >> recently used in a program. I have defined an abstract base class 
  25. >> (i.e. contains pure virtual functions), all access to the derived 
  26. >> classes of this base are thru a pointer to the base class. To create 
  27. >> the actual objects of the derived classes I used the following scheme: 
  28. >>  
  29. >> enum FooType {BAR, BAS}; 
  30. >>  
  31. >> // base class 
  32. >> class CFoo 
  33. >>         { 
  34. >>         CFoo(); 
  35. >>         ~CFoo(); 
  36. >>  
  37. >>         static CFoo* CreateFoo(FooType type); 
  38. >>  
  39. >>         // other methods/data including pure virtual fns whose behaviour
  40.  
  41. >will 
  42. >> be defined in the derived classes 
  43. >>         }; 
  44. >>  
  45. >> class CBar: public CFoo 
  46. >>         { 
  47. >>         // 
  48. >>         }; 
  49. >>  
  50. >> class CBas: public CFoo 
  51. >>         { 
  52. >>         // 
  53. >>         }; 
  54. >>  
  55. >> CFoo* CFoo::CreateFoo(FooType type) 
  56. >>         { 
  57. >>         CFoo* pfoo = NULL; 
  58. >>  
  59. >>         switch (type) 
  60. >>                 { 
  61. >>                 case BAR: 
  62. >>                         pfoo = new CBar; 
  63. >>                         break; 
  64. >>                 case BAS: 
  65. >>                         pfoo = new CBas; 
  66. >>                         break; 
  67. >>                 } 
  68. >>  
  69. >>         return pfoo; 
  70. >>         } 
  71. >>  
  72. >> main() 
  73. >>         { 
  74. >>         CFoo* interface = CFoo::CreateFoo(BAR); 
  75. >>         } 
  76. >>  
  77. >> Obviously it is the CreateFoo() function that I am wondering about. In 
  78. >> the actual implementation I had multiple static "Create" functions for 
  79. >> the base class that would allow me to create a new object: one based 
  80. >> on an enumerated token (shown above), another an existing object, as 
  81. >> well as one based on the format of a datafile. My application never 
  82. >> references any of the derived classes directly, except in their 
  83. >> creation and definition. 
  84. >>  
  85. >> Is there another/better/more appropriate way to handle this type of 
  86. >> object creation? Thanks for your assistance, 
  87. >>  
  88. >> Regards, 
  89. >> -Michael. 
  90. >>  
  91. >> /* 
  92. >>  * catello@magicnet.net 
  93. >>  * http://www.magicnet.net/~catello 
  94. >>  * CompuServe: 70401,3661 
  95. >>  */Hi, 
  96. >I looked at your code snippet and was slightly confused. In your  
  97. >CreateFoo method of CFoo class, the pfoo variable is a pointer  
  98. >to CFoo which has no idea of what are CBas or CBar. But in your  
  99. >code you are creating CBas as well as CBar objects and storing  
  100. >it in pfoo. In your derived CBar and CBas you would obviously  
  101. >have more data members which CFoo* would not be addressing. The  
  102. >compiler should crib at you at  places like "pfoo = new CBas"  
  103. >and "pfoo = new CBar". I wouldn't do it like this. 
  104. > 
  105. How would you do it -- and achieve the stated goals? 
  106.  
  107. BTW, the statement "pfoo = new CBas;" is perfectly legal, 
  108. and even proper.  Any compiler that "cribs" about it is wrong. 
  109.  
  110. -- 
  111. Pete Grant 
  112. Kalevi, Inc. 
  113. Software Engineering & development
  114.